[やってみた]EventiBridge Pipesが生成するロールとポリシーを確認してみた

いくつかのパイプを作成してEventBridge Pipesで生成されるロールやポリシーを確認してみました。

AWS re:Invent 2022

#Amazon EventBridge Pipes

#AWS

佐藤智樹

2023.01.04

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

CX事業本部の佐藤智樹です。

今回はEventiBridge Pipesでいくつかのパターンでパイプを作成し、どんなロールが生成されるのか確認してみました。EventBridge Pipes(以降Pipes)自体の役割は分かっていたのですが、どのように各リソースに対して権限を持つのか分からなく、CloudFormationでPipesを生成する場合にロールは自動生成にならなかったロールは自動生成にならなかったのでまず何ができるのか確認してみました。

結論

Pipesは、各ソース(Source)、強化(Enrichment)、ターゲット(Target)で設定したサービスに対するオーケストレータとなるため、ソースからはイベント情報の取得、強化/ターゲットにはイベント情報の通知を行うために必要な最低限の権限だけが与えられます。図で示すと以下のような関係になります。

上の概要図はソースとしてDynamoDB Streamからデータを取得し、強化でAPI Gatewayを実行し、ターゲットとしてLambdaを実行する場合です。Pipesをコンソールから作った場合、ソース、強化、ターゲットごとに個別のポリシーが生成され、Pipesに紐付けられたロールにポリシーが付与されます。ポリシーは最小権限の原則に沿ったリソースやアクションが設定されます。詳細が気になる場合は後半を確認ください。

Pipesを作ってみる

以下の2つのパターンでパイプを作ってどんなロールやポリシーが作成されるのか、ターゲットなどを変更時にロールやポリシーに再反映できるのかを確認します。

パターン1：SQS(ソース)→Lambda(ターゲット)
パターン2：DynamoDB Stream(ソース)→フィルター→API Gateway(強化)→Lambda(ターゲット)

パターン1

SQS(ソース)→Lambda(ターゲット)でパイプを作成してみます。フィルターと強化は省いて最低限の状態で何が生成されるのかを確認します。実際にパイプを作成するとAmazon_EventBridge_Pipe_{パイプ名}_{ハッシュ値}のサービスロールが生成され、それぞれのソースターゲットごとにポリシー名{リソース名}Pipe{Source|Target}Template-{ハッシュ値}のポリシーが生成されます。以下は全体の概要図です。

ポリシーはそれぞれ以下のようになっています。

SQS用Policy

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "sqs:ReceiveMessage",
                "sqs:DeleteMessage",
                "sqs:GetQueueAttributes"
            ],
            "Resource": [
                "arn:aws:sqs:ap-northeast-1:123456789012:sample-queue"
            ]
        }
    ]
}

Lambda用Policy

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "lambda:InvokeFunction"
            ],
            "Resource": [
                "arn:aws:lambda:ap-northeast-1:123456789012:function:sample-lambda"
            ]
        }
    ]
}

上記ポリシーは必要なソースからのデータ取得に必要なアクションと対象リソース、ターゲット実行に必要な最低限のアクションと対象リソースに自動で設定されるため最小権限の原則を自動で満たすことができます。

パターン2

次はDynamoDB Stream(ソース)→フィルター→API Gateway(強化)→Lambda(ターゲット)でパイプを作成してみます。こちらはフィルターと強化を追加して内容を確認してみます。

概要図は以下のようになります。(再掲)

ロール名やポリシー名の規則はパターン1と変わらず、強化に対するポリシーもターゲットと同じようなポリシー名になるという部分だけが新しい内容でした。次に実際のポリシーを確認します。

DynamoDB Stream用Policy

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "dynamodb:DescribeStream",
                "dynamodb:GetRecords",
                "dynamodb:GetShardIterator",
                "dynamodb:ListStreams"
            ],
            "Resource": [
                "arn:aws:dynamodb:ap-northeast-1:123456789012:table/pipe-sample/stream/2023-01-03T13:22:12.773"
            ]
        }
    ]
}

API Gateway用Policy

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "execute-api:Invoke",
                "execute-api:ManageConnections"
            ],
            "Resource": [
                "arn:aws:execute-api:ap-northeast-1:123456789012:xxxxxxxxxx/prod/*"
            ]
        }
    ]
}

Lambda用Policy

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "lambda:InvokeFunction"
            ],
            "Resource": [
                "arn:aws:lambda:ap-northeast-1:123456789012:function:sample-lambda"
            ]
        }
    ]
}

上記ポリシーはパターン1と同じようにデータを取得/イベント実行するための最小限のポリシーで設定されていました。API Gatewayはprod配下*になっています。prod配下のエンドポイントも指定してみましたが、ポリシーのリソース対象の設定はこれ以上詳細には設定されませんでした。